@badeend We don't have illumos in CI, but I do occasionally test rustix on illumos, but with this PR, on illumos, sockopt::test_sockets_ipv4 (but not sockopt::test_sockets_ipv6) now fails with this error:

thread 'sockopt::test_sockopts_ipv4' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', tests/net/sockopt.rs:167:78

At a quick search, I found this illumos bug report which on the surface looks similar.

It's not formally necessary for wasi-sockets to support illumos, but it is worth considering whether there's something we should do there.

In case it's relevant, the illumos version is openindiana 2023.05.

That bug report and the source code seem to suggest that the order in which the options are set matters. I haven't been able to decipher the illumos source, but the bug report mentions that set_tcp_keepintvl before set_tcp_keepcnt should work (?)

I don't have an illumos install, so I can't test it easily but do these changes work for you?: badeend@771f027 If not, how about when set_tcp_keepintvl and set_tcp_keepcnt are swapped around?

It's not formally necessary for wasi-sockets to support illumos, but it is worth considering whether there's something we should do there.

Couple of options:

1. Nothing. Let it fail (semi-arbitrarily) like any other application already running on illumos.
2. Let the set_tcp_keepintvl and set_tcp_keepcnt WASI equivalents return not-supported on illumos
3. (If the order is indeed the culprit) Make a custom provision in the WASI implementation for illumos that defers making the actual syscalls until just before connect (for example)

I did some experimenting, and it seems to be related to the integer value. A value of 60 works, but the test has 61 which fails.

I think option 1 may be fine here. This seems sufficiently minor that we don't need to make any changes at this time.

This is now released in rustix 0.38.14.